1. Field of the Invention
The present invention relates in general to the field of information processing, and more specifically to a system and method for extending virtual machines in a resource-constrained device using application contexts that allow virtual machines to exert control over a variety of applications, including native applications, and facilitate extending functionality of the virtual machines.
2. Description of the Related Art
For resource-constrained devices and other computers that employ an operating system, two traditional software layers exist: the operating system and the software programs (or “applications”) that run on the operating system. A resource-constrained device is, for example, a device that has limited resources available for performing computing functions. For example, a resource-constrained device generally has limited memory, limited processing power, and/or limited graphical capabilities. Mobile phones, pagers, and personal digital assistants represent examples of resource-constrained devices. Software applications are programs used on a computer to accomplish particular desired tasks. An operating system is designed to function on a particular type of computer hardware, and an application is designed to run on a particular operating system (and processor). Such operating systems and applications are thus said to be “platform-specific”. The platform specific applications are also commonly referred to as “native applications”.
Platform-specific application programs are first written with a programming language to create a set of instructions called “source code.” When writing source code for a platform-specific application, the developer must be mindful of the underlying operating system, in order to successfully invoke the operating system's application program interfaces (APIs). These API's essentially provide the vocabulary of the language understood by the operating system. If the source code of a platform-specific application is not written to accommodate the particular APIs of a given operating system, then the application will not run on that operating system. Thus, platform-specific applications are dependent on the specific operating system and hardware for which the application was designed and compiled.
Platform-independent applications utilize virtual machine technology, such as Sun Microsystem's Java™ technology, to significantly reduce the difficulty of producing applications for different operating system and hardware platforms. Platform-independent applications developed using the Java technology differ from traditional platform-dependent software in that the platform-independent applications need not interact directly with the specific operating system or hardware of a given computer. Java programs are compiled into an intermediate platform-independent representation called bytecode. At run-time, platform-independent applications typically interact with a Java virtual machine (“JVM”), which is an intermediate software layer that includes a programming language interpreter. The JVM interprets (i.e. translates) the Java-based program for the particular operating system and hardware platform that the Java virtual machine runs on. In essence, the Java-based program views the JVM as an operating system, and the operating system views the JVM as a traditional application.
The Mobile Information Device Profile (MIDP) is a set of Java APIs. The Connected Limited Device Configuration (CLDC) defines the base set of application programming interfaces and a virtual machine for resource-constrained devices such as mobile phones, pagers, and personal digital assistants. The Java virtual machine for resource-constrained devices intended to execute MIDlets is called the kJava Virtual Machine (KVM). Because, the KVM also interprets (i.e. translates) kJava-based programs for the particular operating system and hardware platform that the KVM runs on, the KVM can be considered as a virtual computer and an operating system (OS) from the perspective of kJava based programs. The CLDC combined with a profile such as the Mobile Information Device Profile (MIDP) provides a solid Java platform for developing applications to run on devices with limited memory, limited processing power, and limited graphical capabilities. Thus, the MIDP together with the Connected Limited Device Configuration (CLDC) provides a complete J2ME™ application runtime environment targeted to mobile information devices. A MIDlet is a Java application developed using the MIDP, and intended to be run on a mobile information device.
As processing capabilities, bandwidth, and other technologies improve, mobile information devices become more and more powerful and are capable of performing an increasing number of functions. Concurrently executing multiple applications (referred to as “multi-tasking”) has become a standard feature of mobile information devices. For example, it is relatively common to concurrently execute a phone-call handling routine, game, and a phone-book application.
FIG. 1 depicts a resource-constrained device 100. Multitasking generally involves one central processing unit (CPU) 102 switching from one application to another quickly, thus, giving the appearance of concurrently executing all of the applications. A state of each application 104 in memory 106 must be maintained between application switching events. The states of platform independent applications 108, i.e. applications such as MIDlets under the control of the KVM, are maintained by the KVM 110. The states of native applications 112, i.e. applications under the control of the native OS 114 or native processing features of the CPU 102, are maintained by the OS 114 or native processing feature of the CPU 102.
An “event” encompasses actions initiated either by a user of a computer or internally generated by the computer. An example of a user event is any mouse movement, mouse click, keystroke, or a spoken word. An example of an internally generated event is a notification based on the time of day. If an event is passed to the KVM 110, a corresponding Java or native method (handler) is found and invoked. An event handler is generally a software routine that provides processing instructions for various events. For methods that are supposed to be frequently invoked, a mobile information device 100 can accomplish invoking frequently invoked applications using a special reference table. The applications can be registered in the table during implementation of a KVM 110.
Current software architectural technologies cannot be efficiently applied to embedded software development. Embedded software represents, for example, software applications that provide various basic services such as menu displays, phone-calling handling, and some standard games. Currently no mechanisms exist to allow a native application to run under control of the KVM. Any native application that should be executed while the KVM is running runs as a parallel process on the OS level. There will not be full resource sharing (or may not be sharing at all) and no control from the KVM side.
FIG. 2 depicts a conventional OS functionality addition methodology 200 for adding new functionality to an OS of a resource-constrained device such as a mobile phone when the OS does not support the functionality. In operation 202, if the OS supports the functionality and interpreter 204 is called, the function is provided by the resource-constrained device 100. In operation 202, if the OS does not support the new functionality, an OS programmer can choose in operation 206 whether or not to add functionality to the OS. The programmer can change the OS in operation 208, and the revised OS can then be installed in resource-constrained devices. During operation, the resource-constrained device then makes the new functionality available to a user through an interpreter call 204. Alternatively, if new functionality is not added to a new OS, in operation 210 a new operating system must be developed or purchased/licensed and integrated into each resource-constrained device as respectively depicted in operations 212 and 214. Once the new OS is installed, the new functionality is available via an interpreter call 204.
FIG. 3 depicts a conventional methodology 300 for providing an application to add external support functionality, such as statistics gathering support, to a virtual machine. Operation 302 stops the virtual machine execution. In operation 304, a person, such as a virtual machine programmer, adds/creates the new functionality inside the virtual machine, such as the KVM 110. Operation 306 builds and links the new virtual machine with the new functionality. In operation 308, the new virtual machine is downloaded to a constrained-resource device. Operation 310 starts the new virtual machine by, for example, activating the constrained-resource device. The constrained-resource device can now use the new functionality, e.g. the new statistics service, in operation 312. The methodology 300 cannot be implemented in a run-time environment. To disable the functionality implemented by methodology 300, the revised virtual machine is stopped and the old virtual machine is loaded.
FIG. 4 depicts a conventional methodology 400 for providing an application to add internal support functionality, such as a plug-in to support a new mobile phone, to a virtual machine. Operation 402 stops the virtual machine execution. In operation 404, a person, such as a virtual machine programmer, adds/creates a virtual machine function to provide native-type support for applications requesting native support. Operation 406 builds and links the new virtual machine with the new functionality. In operation 408, the new virtual machine is downloaded along with the plug-in to a constrained-resource device. Operation 410 starts the new virtual machine by, for example, activating the constrained-resource device. The constrained-resource device can now use the new functionality, e.g. the plug-in application, in operation 412. The methodology 400 cannot be implemented in a run-time environment.
Java programs can be written to include a portion written in a non-Java programming language to access functionality not yet supported in the Java technology, but which may be available in the underlying (“native”) operating system or hardware. To do this, the Java technology includes a “Java Native Interface” (JNI). JNI is a standard Java API that acts as a link between the JVM and the platform-specific code included in a JAVA application to perform the particular operating-system function. JNI thus gives programmers a way to use native platform functionality with their Java-based software. However, conventional JAVA technology does not support JVM control over pure native applications.
Adding new OS and virtual machine functionality or choosing or creating a new OS can, thus, be expensive, time-consuming, and difficult to distribute to then-existing resource-constrained devices.